Day 10｜Context Window 是什麼：限制與迷思

從今天開始要進入 Part3，會介紹Context Engineering的內容。先從最基本的概念講起: 甚麼是Context window?

Context Window 是什麼

每次呼叫 LLM，模型能「看到」的內容是有上限的，你送進去的所有內容（系統指令、對話歷史、這次的問題）加上模型要生成的回應，全部加起來不能超過這個模型設定的 token 上限，這個上限就叫 context window。

超過這個上限會發生什麼事？通常 API 會直接回傳一個錯誤，拒絕這次請求，也就是 Day 5有提及過的「400 系列的請求錯誤」的其中一種情況。

目前主流模型的 context window 大小都不一樣，而且這個數字幾乎每隔一段時間就會往上調整，在使用前可以查閱一下官方文件設定。

常見的迷思：窗口大 ≠ 全部都記得住

Context window 變大之後，常見的誤解是「既然可以塞這麼多內容，乾脆什麼都塞進去，反正模型『看得到』」。但實際上不完全是這樣：

• 不是所有位置的資訊都被同等重視：有研究觀察到一個現象，叫做「lost in the middle」——當一段很長的內容裡，重要資訊被塞在中間位置時，模型抓取的準確度會比資訊放在開頭或結尾時來得差。

• 塞越多，花越多：多數廠商是依照 input token 數量計費，塞進去的每一段內容都要付費，不會因為「反正是沒用到的資訊」就免費。

• 多輪對話會不斷累積：如果把每一輪的對話歷史原封不動地往後疊加，對話越長，送出去的 messages 就越長，遲早會逼近甚至超過 context window 的上限。

怎麼知道自己現在用了多少

多數 SDK 都有提供「算 token 數」的工具或端點，可以在真的送出請求之前，先估算一段內容大概要花多少 token，這樣也方便提前抓好每次請求還剩多少空間可以用，而不是等到收到超過上限的錯誤才發現。

小結

Context window 是模型的「工作記憶」上限，但重點不在「這個數字有多大」，而在於你怎麼有效利用這個空間，知道哪些內容真正需要留在裡面、哪些是可以捨棄或壓縮的。

明天的文章會分享，當對話內容累積的越來越長，有甚麼方法可以做管理與切割，讓模型盡量讀取最重要的資訊，而不是任由資訊量一直累積直到超過上限。